The AIN is a network architecture used by all modern telephone switching systems in the United States. The AIN is applicable to all telecommunications networks (e.g. Public Switched Telephone Networks (PSTNs) including Integrated Services Digital Networks (ISDNs)), narrowband, broadband, packet-switched public data networks, and mobile telephone networks. FIG. 1 represents a simplified diagram of the AIN configured by a Local Exchange Carrier (LEC). The components of the AIN include: (i) a central office 102 containing a switching system 104 such as a Service Switching Point (SSP); (ii) a signaling network 106 composed of a multi-level hierarchy of Signal Transfer Point (STPs) which act as intermediate switching nodes; and (iii) a Service Control Point 108 (SCP) which contains a centralized database. Each of the central offices 102 is equipped with a SSP 104. In, AIN, the SSP 104 is a switch that can recognize a call that requires AIN processing by the SCP 108.
To exemplify a service provided by the AIN, consider a customer placing a telephone call that requires special handling, such as a toll-free call (800 service). The call is intercepted by the switching system 104 which launches a query through the signaling network 106 to a centralized database located in the SCP 108. The database, in turn, retrieves the necessary information to handle the call, and performs a number translation to map the "logical" 800 number to a "physical" routing number. The physical routing information is returned through the signaling network 106 to the switching system 104 so that the call can be completed. Number translation is an example of one of a plurality of so-called service categories defined for the AIN. Each service category serviced by the SCP 108 is composed of the logic that handles the query/reply transaction between the SSP 104 and the SCP 108.
FIG. 1 also shows multiple subscriber lines 110, typically on the order of 10,000 to 70,000 lines, which are connected to each central office 102. Each of the subscriber lines 110 are connected to a terminating piece of telephone equipment 112. This telephone equipment 112 can include telephone sets, facsimile machines, computers, and automatic dialers. Trunk circuits 114 interconnect the central offices 102 and are the voice path that connect inter-office communications when calls are completed.
Triggering is the process used by the SSP 104 to identify calls that require special handling by the AIN. The SSP 104 has the appropriate hardware and software so that when a set of predetermined conditions are detected, the SSP 104 will encounter a trigger 116 in response to activity on the dialing lines. A trigger 116 is an event associated with a particular subscriber line 110 that generates a query to be sent to the SCP 108. A trigger detection point (TDP) is a point in call processing where service logic can receive notification of a given event and influence subsequent call processing. The trigger 116 includes information for identifying particular subscriber lines 110 when a piece of telephone equipment connected to a line goes off-hook, commences dialing, etc. Once a trigger 116 is encountered, the SSP 104 temporarily suspends call processing. Each trigger 116 generates a query in the form of a data packet launched by the SSP 104 to the SCP 108 to ask for instructions on how to handle the call and obtain the required call handling information. The data packet is first sent via bidirectional data links 118 utilizing the Signaling System 7 (SS7) protocol to the STP 106. The SS7 distributes data packets on an equal basis over multiple physical links that connect two points, namely the SCP 108 and STP 106. The STP 106 is a very high capacity, very reliable packet switch that can transport messages between network nodes such as the SSP 104 and SCP 108. The STP 106 essentially directs traffic on the network and routes the data packet to its intended destination (i.e. the SCP) via high speed data links 120.
The SCP 108 is a fault tolerant transaction processing system that contains various centralized databases that provide the appropriate call routing information and identify particular subscribers. The SCP 108 responds to a request (i.e. trigger) received from the SSP 104. The trigger 116 causes the SCP 108 to query its databases to determine whether some customer calling feature or enhanced service should be implemented for this particular call or whether conventional dial-up telephone service should provide for the call. The results of the database query are sent back in the form of a return packet over the data links 120 through the STP 106 and onward through data links 118 to the SSP 104. The return of the packet includes instructions to the SSP 104 on how to continue processing the call.
Open access to the AIN operated by LECs to third parties will exploit the capabilities and efficiencies of third party service providers and enable these third parties to provide competitive telephone related services to local LEC subscribers.
Representative of an approach of the prior art which relates to providing open access to the AIN to exploit third party capabilities and efficiencies is the paper entitled "Solutions for Mediated Access to the Intelligent Network" by Wayne Heinmiller, Ron Schwartz, and Marianne Stanke disclosed at ISS '95, April 1995, Vol. 2. The paper proposed a service architecture that allows access to the IN from a SCP belonging to any service provider and defines a set of new network functions referred to as mediation which reside in a network element labeled the mediation point (MP). The resulting logical network architecture is shown in FIG. 2. The key attribute of this architecture is the MP 200 which is the point of interconnection for the service provider's SCP (108, 202, and 204 respectively) and the SSP 104. The MP 200 is situated between the SSP 104 and a number of SCPs (SCP 108, SCP 202, and SCP 204). Data link 206 connects the MP 200 to the SSP 104. Data links 208, 210, and 212 connect the MP 200 to the SCP 108, 202 and 204 respectively. The MP is intended to be transparent to the transactions between the SSP and SCPs.
So-called "feature interactions" in a distributed call processing environment such as the IN become a problem when using the architecture depicted in FIG. 2. The phrase "feature interactions" describes, for example, the outcome of an action which invokes execution by a plurality of SCPs servicing the features. For instance, if A represents a feature serviced by one SCP and B another feature serviced by another SCP, then different outcomes are possible if A and B are queried: (i) sequentially with A first; (ii) sequentially with B first; or (iii) simultaneously. Regarding this problem, the paper states that a successful solution must prevent destructive side-effects, support multiple independent service providers, and have no knowledge of the actual service particulars while satisfying all of the users' service requirements--this is a very difficult, if not impossible, task. In addition, the ability to combine services must be customizable to meet the particular needs of each user, and the ability to do so should be open to competition and not be the sole purview of the telephone administration.
After considering the above mentioned factors, the authors of the paper conclude that the need for a universal, generic solution to feature interactions is not possible, and probably not even desirable. Service providers want the resolution of feature interactions to be located outside the network, where any service provider can work with users to customize solutions based on that user's needs. Alternatively, the user can work with a "services broker" who will consult with the user to select one or more service providers and consider appropriate interactions. Since feature interactions often require a greater degree of communications, the authors foresee the need for direct SCP-to-SCP connections among service providers to mitigate feature interaction effects. The SCP-to-SCP connections would occur if the service providers determine it is to their benefit to deliver improved feature interactions to their customers.
To date, much of the other work accomplished to provide open access to the AIN operated by LECs has assumed that for any given subscriber (i.e. LEC customer who subscribes to one or more service categories invoked by a particular trigger), all service categories invoked by encountering a particular trigger would have to be provided by the same service provider system. In other words, only a single SCP would have access to a specific trigger active on a given subscriber's line. A SCP can be owned by a LEC or a third party.
There are problems inherent in only a single SCP having access to a specific trigger active on a given subscriber's line. For example, this greatly limits the number of services or service combinations a subscriber may have, and diminishes the original intent of opening the AIN to third parties. In addition, it allows one service provider to monopolize a particular trigger active for a given subscriber, because no other service provider can subsequently provide a service to that subscriber using the same trigger. Thus, a need still exists to provide open access to the AIN so that capabilities and efficiencies of third parties can be exploited.
Moreover, as elucidated above, the teachings and suggestions in the prior art suggest a universal, generic solution to the feature interaction problem is virtually impossible. This pedagogy provided by the teachings and suggestions of the prior art serve as a point of departure from the art in accordance with the subject matter of the present invention. There are no known attempts to create a general methodology to generate and use controlling logic for management of communications among nodes in an AIN and, in particular, feature interactions in a SSP-multiple SCP environment.